As the development of computer systems continues, a corresponding burden is placed on supporting software. As one key example, as hardware becomes more sophisticated, so does the need for refined and/or additional hardware drivers. A driver is a computer program which allows a specific piece of hardware to communicate with an operating system or environment. This example is demonstrated in the computer environment currently created by MICROSOFT WINDOWS. Typically, when operating under WINDOWS, a new device driver must be installed when an operator adds a new device to the underlying computer system.
The present invention arises in connection with driver compatibility and advancements in video subsystems. Particularly, a change in a video configuration (e.g., video controller) often requires, or benefits from, a corresponding change in the video driver. For example, one relatively recent computer development is the creation of so-called docking bays. A docking bay is a hardware setup where a desktop chassis has a bay which accepts a laptop computer. The desktop chassis then uses the processor of the laptop for processing and to operate peripherals typically associated with the desktop computer. Thus, when the laptop is removed from the docking bay, its video driver must support the laptop video configuration which typically includes a flat panel display (such as an LCD screen). Conversely, when the laptop is inserted into the docking bay, the chassis of the desktop bay most likely includes a more versatile video configuration including a CRT monitor. Often the monitor supports higher resolution and/or a greater number of colors than the flat panel display of the laptop. Indeed, most modern laptops have insufficient power and/or space to support the more sophisticated video technology available in larger machines such as desktop computers. Consequently, the monitor of a larger machine often uses a separate and more advanced video controller which, in turn, operates optimally only if the corresponding video driver is selected to drive the advanced controller.
Under currently known systems, an operator is required to manually change the video driver to accommodate the docking bay scenario described above. Thus, before removing the laptop from the docking bay, the operator interacts with the computer to select the video driver necessary to drive the laptop configuration once the laptop is removed from the bay. Typically, this operation is performed using either the WINDOWS Setup or Control Panel function. Later, either before or after inserting the laptop into the docking bay, the user again interacts with the computer and changes the video driver. In this instance, the user selects the driver necessary to drive the configuration of the desktop computer.
Without necessarily limiting the present invention, note that the concepts discussed and claimed below have various advantages in connection with the WINDOWS environment. Accordingly, FIG. 1 illustrates a pictorial view of a subsystem 10 of WINDOWS responsible for, among other things, controlling graphic subsystems such as printers, plotters, monitors, screens and the like. FIG. 1 further illustrates the interaction of a program application 12 with the software components of subsystem 10.
Subsystem 10 includes a graphics device interface (GDI) 14, a window manager 16 and a video driver 18. GDI 14 handles the protocol between application 12 and video driver 18. Note also that GDI 14 handles protocol between application 12 and additional components (not shown) in the WINDOWS system. Window manager 16 generally supervises the overall visual presentation to the user, such as the size, location and visibility of an item (e.g., a window, an icon) as displayed on a graphics device.
Each of the components within subsystem 10 further includes an applications programmer's interface (API), denoted 14a, 16a and 18a, respectively. As known in the art, the API are entry points corresponding to certain minimum functions required to ensure WINDOWS compatibility. Thus, the API are specified so that a programmer may properly draft code to communicate with WINDOWS protocol. Thus, for a given component within subsystem 10, such as GDI 14, a programmer is provided a set of API entry points 14a where each point corresponds to a particular function(s). Accordingly, the programmer may write his or her code to communicate with a given API entry point to accomplish a function(s) corresponding to that point.
Note that any WINDOWS-compatible device driver, such as video driver 18, also includes API entry points 18a through which programmers can effect the functionality of the driver, and its corresponding hardware device. This driver functionality is required to match at least the minimum functionality requirements set forth by WINDOWS.
Video driver 18 further includes a set of resources 18b. Resources 18b typically include items such as bit maps for items like cursors, menu boxes, maximize/minimize boxes, other icons, etc. Resources are based on display size and, hence, differ vastly on a device-to-device basis. The resources are pure data rather than a function which is called. For example, resource bit maps may be identified with a pointer in combination with a draw function which will draw in accordance with the identified bit map. Thus, an icon or other resource may be displayed in this manner.
The typical interaction of application 12 with subsystem 10 is as follows. When WINDOWS is loaded, a kernel (not shown) oversees the loading of the various pieces for baseline operations. The kernel reviews a file typically denoted "SYSTEM.INI" to determine the initial setup for the particular WINDOWS environment. The SYSTEM.INI file includes, among other things, an identification of the video driver previously selected by a user as described above. Thus, the kernel loads the previously identified video driver. Thereafter, the kernel loads GDI 14 and window manager 16.
After video driver 18 is loaded, window manager 16 issues an inquire command. Next, GDI 14 issues an enable command along with a pointer identifying a location within GDI 14. In response, video driver 18 returns infostructure information to the GDI data structure commencing at the address identified by the pointer. Such information concerns the video driver/device, such as which functions are supported, display size, color format, aspect ratio, etc. In addition, both GDI 14 and window manager 16 create tables 14b and 16b, respectively, which identify the API entry points 18a of video driver 18 corresponding to particular functions which may be called by either GDI 14 or window manager 16.
To perform a given video function, application 12 performs a Call to the API of either GDI 14 or window manager 16. Typically, the majority of Calls for video purposes are made to GDI 14. Thus, for example, consider the instance where application 12 calls GDI 14. More particularly, application 12 issues a Call to API 14a of GDI 14. In response, GDI 14 issues the appropriate Call or Calls to API 18a of video driver 18.
Note that the number of Calls from GDI 14 depends on the particular function as well as the sophistication of the functionality for a given video driver 18. Particularly, certain device drivers may include advanced functions (and corresponding API) above and beyond that required by WINDOWS. Thus, if one of these advanced functions is being requested by application 12, GDI 14 may directly access the corresponding API 18a of video driver 18. If the advanced function is not provided by video driver 18, then GDI 14 translates the application request into constituent requests to the video driver. The constituent requests are performed using the minimal set of functions required of the video driver. Accordingly, the functions performed by the constituent requests combine to accomplish the more sophisticated request initially provided by application 12.
In view of the above, it should be appreciated that the WINDOWS environment, as exemplified in combination with the use of docking bays, creates situations involving changes in video drivers. The frequency of driver change is naturally affected by the frequency of insertion/removal of the laptop in/out of the desktop docking bay. Note that the need to re-select and/or reconfigure a driver also may arise due to a change in the video system. Thus, even absent the docking bay example, an operator may change an existing video controller within a computer (e.g., desktop) and, hence, create the need to also change the appropriate video driver. Indeed, as computers further develop, it is believed that other alternative arrangements may evolve also requiring a relatively frequent change in video driver selection. Accordingly, in each of the-above scenarios, as well as those developed in the future, it is an object of the present invention to provide a method for automatically selecting an appropriate video system driver based on the current video system configuration.
It is a further object of the present invention to provide a method for compiling information about the protocol exchanged between the WINDOWS subsystem and a particular video driver.
It is a further object of the present invention to provide a method for providing access to driver resources.
It is a further object of the present invention to provide a method for controlling the kernel flag to prevent an erroneous indication that video driver resources have been pre-processed.
Still other objects and advantages of the present invention will be readily apparent to a person having skill in the art with reference to the following description, figures and claims.